Individuals are increasingly engaging in electronic communications with other individuals, electronic services, and resources over the Internet. In many cases, these communications need to be secured and trusted, such that the parties can assure one another as to the true identity of the participants engaging in the communications. This is so, because the communications that occur during these transactions can unwittingly expose confidential data about the participants. However, there is a tradeoff between improving security and flexibility/management, such that security is adequate enough but any technique used is not too rigid, too cumbersome, and too difficult to establish and manage.
One conventional technique that permits a trusted relationship between two or more parties is to maintain and manage a separate trusted data store in each of the local processing environments of the parties. Each trusted data store includes identifiers for the remaining parties and includes a unique public key certificate for each of the remaining parties. The public key certificates are used to encrypt communications directed to the remaining parties, when the communications are occurring over non-secure communication lines or with non-secure protocols. The problem with this approach is that it is too difficult to manage and too cumbersome, because several disparate trusted data stores must be kept in synchronization with one another and because sometimes a particular party may use a different computing device or move an existing computing device (e.g., laptop, personal digital assistant, cell phone, etc.) from its typical network service provider (e.g., Internet Service Provider (ISP), or other Service Providers (SP)).
When a party becomes mobile, he/she divorces himself/herself from a particular processing device or SP environment. Correspondingly, a needed trusted data store may not be available to the party and/or a private key associated with a party's public-private key pair may not be available for that party to access. Thus, this technique does not provide a continuously and reliable level of service to the parties involved.
Another technique is to establish dedicated and secured transmission lines between trusted parties. With this technique, the parties are physically tied to their existing processing devices and SP environments, since any deviation will not make the secure transmissions lines available for pre-defined and trusted relationships. This technique may offer the highest degree of security, but it is also the most rigid, the most inflexible, and much too costly for the vast majority of individuals that access the Internet on a casual or personal basis.
Still other techniques are geared towards commercial SPs, in these arrangements SPs pay to have a static and strongly rooted public key administered from a third-party service (e.g., Verisign), any needed public key for a particular participating SP can be acquired from the third-party. The problem with this technique is that a typical end-user or small entity may not be able to afford the services of the third-party. Furthermore, any participating SP is still rigidly tied to a static public key. This means that should an Internet Protocol (IP) address for a participating SP change, then the third-party may need to be synchronized with a new public key. Moreover, this is useful only when all parties to the relationship are subscribers to the third-party service, since all parties in a trusted relationship need to communicate their respective and valid public keys to the remaining parties. Thus, these techniques are still too costly, too rigid, and designed to assist and benefit only SPs, not a causal Internet end-user.
Thus, improved techniques for dynamically establishing and managing trust relationships are needed.